ITU-T Recommendation G.7044/Y.1347 (10/11) “Hitless adjustment of ODUflex (GFP)” (henceforth referred to as G.HAO), the contents of which are incorporated by reference herein, is a resizing mechanism within Optical Transport Network (OTN) that supports an increase or decrease of an ODUflex (GFP) client data rate across its entire end-to-end path. Since the ODUflex gets carried across the links as a single switched payload unit and not as individual units (unlike Virtual Concatenation (VCAT)), the following are prerequisites for supporting hitless resize of ODUflex (GFP): 1. All nodes in the path support G.HAO protocol; 2. The ODUflex occupies same number of tributary slots (TS) in a High Order (HO) Optical channel Path Unit-k (OPUk) for all links in the path, i.e., there are no asymmetric configurations; and 3. All links in the path have the bandwidth (i.e., number of TSs) available to resize the ODUflex to the desired rate.
However, conventionally, the resizability information (i.e., 1. whether symmetric or not; and 2. number of available TSs for hitless bandwidth increase which are constrained by the link with minimum available TSs along the connection path) is not available at the ODUflex (GFP) resizing control points (which could be the ODUflex client originating and terminating Connection Termination Points (CTPs) or the originating/terminating Subnetwork Connection (SNC) endpoints, for example) for the operator to make an informed choice on how much the ODUflex connection can resize hitlessly. Operators, therefore, have to attempt a trial and error mechanism before the hitless resizing succeeds. In case of manual cross-connects or mixed cross-connect/control plane connections, the framework to distribute the resizability information to ingress/egress client endpoints would be very tedious involving many control/management planes talking to each other. Even though this information is available to a distributed control plane on each intermediate node in cases of path setup through the control plane, the same is not communicated to the originating or terminating endpoints. In both the scenarios, however, the information cannot be communicated in real-time, i.e., as and when the bandwidth on any link along the path changes, but would involve software and communication delays.
There is no mechanism proposed in G.HAO to get the resizability information across a complete path. Any control plane-based solution has/would have the various limitations. It can only advertise the resizability information (bandwidth available and whether resizable) if the complete end-to-end ODUflex (GFP) path is setup by the control plane and is not a generic solution for mixed control-plane/management plane (manual cross-connect) paths or only manual cross-connect paths. It is not real-time due to distributed nature of software and software delays in propagating the information.